Subject: Boeing Mapped Data Conversion (mapped Conversations) Proposal

From: "Hildebrand, Jeff" <[email-masked]>
Date: Wed, 17 Nov 93 10:57:00 PST

This is the Boeing contribution for mapped data conversion, also known
as mapped conversations.  This paper presents:
     1.Requirements.
     2.The two proposed calls.
     3.How the calls work with each CRM.
     4.Interoperability between partners where one does not support
           these calls.
If you have any comments please send them to me and I will try to respond
promptly.

Kindest regards,
Jeff Hildebrand
Boeing
[email-masked]
206/865-4893

Requirements:
Traditionally the encoding and decoding of data has been a problem
the application programmer dealt with.  The advent of the LU 6.2
protocol saw the first mention that the encoding and decoding of
network data streams could be separated from the application
program and given to the underlying system (footnote 1).  LU 6.2
describes a user written routine node services calls to perform
either encoding or decoding of a network data stream.  This method
allows all programs that process a specific transaction type to use
a common routine, ensuring uniform processing and eliminating a
significant programming task for the application programmer.
These routines were envisioned to allow not only data conversion
but also preprocessing of the data, for example, rearranging fields
to suit a local record format.  Unfortunately, the concept as
specified in the LU 6.2 protocol was not implemented.  What was
implemented is a mechanism which chops an application's data stream
into regular size chunks for transmission and reconstructs the data
record on the receiver's side.  What has become known as mapped
conversations in the LU 6.2 environment is really a
simple buffering mechanism.

OSI TP has a need for mapped conversations as described in the LU 6.2
protocol.  The ASN.1 encoding and decoding of network data streams
can be laborious, error prone and a significant portion of the
application program's code.  Architecturally OSI TP addressed this
problem by removing the encoding and decoding from the application
program and placing it in the U-ASE which is located in the OSI CRM.
This approach provides three advantages:

     1.It allows the applications programmer to focus on the problem
       to be solved rather than the mechanical encoding and
          decoding of data.
     2.A small group of one or two people can support an organization
       in the construction and maintenance of U-ASEs.  These people
       can develop the required skills to economically create and
          maintain U-ASEs that only repetitive usage provides.
     3.A single U-ASE can be used by many programs and realizes all
       the benefits of code-reuse.

The problem this proposal addresses is the need for CPIC to support more
sophisticated network encoding methods then it currently does, so that
it can support heterogeneous platforms and CRMs.  At the same time,
that support must be done in a way that insulates the application
programmer from:
     1.Duplicating the same encoding and decoding routines in every
       program, which  results in:
        A.Diverting the application programmer's attention from
          the task to be solved to mechanical encoding and decoding
             problems.
        B.Introducing errors by not being able to reuse encoding
           and decoding code.
     2.The details of the underlying encoding method.  This allows
       system administrators to decide which encoding methods to
       use and not disturb existing application programs if they
       change a method.  For example, the same system might use
       either a proprietary or ASN.1 encoding depending on the
       partner.

Proposal:
This proposal views an application program sitting on top of CPIC with
CPIC requesting and receiving services from the underlying CRM.  All
encoding and decoding of data occurring either in the application
program or in the CRM.  CPIC is not involved in the encode/decode
process, except as a pass through mechanism.  The SET_MAP_NAME call
provides a mechanism for the application program to inform the CRM
how to encode the user data it will process on a send data.
The EXTRACT_MAP_NAME call provides a means by which the CRM can
inform the application program what data record it received.
The data record is delivered to the application program decoded and
ready for use.  These calls do not change any CPIC state.

 ----- Start proposed service calls ----

Set_Map_Name (CMSTMP)

A program uses the Set_Map_Name (CMSTMP) call to communicate to the
local system what data record the application program is going to send.
The remote partner program uses the Extract_Map_Name to retrieve the
name of the data record it was sent.  This service must be used if
the program sends multiple data record types.  It may be ignored if the
mapped conversation only supports one data record type.

Depending on the underlying CRM the data record may be further
processed when it is given to the local system at SEND_DATA time,
see usage notes.

Format
CALL CMSTMP    (conversation_ID,
               map_name,
               return_code)
Parameters

Conversation_ID (input)
     Specifies the variable containing the conversation identifier
     assigned to the conversation.
map_name (input)
     Specifies the mapping function to be used to encode the data
     record.  This is a positive integer value.
return_code (output)
     Specifies the result of call execution.  The return_code
     variable can have one of the following values:
          *CM_OK
          *CM_PROGRAM_STATE_CHECK
            This value indicates the underlying CRM does not support
            mapped conversations.
          *CM_OPERATION_NOT_ACCEPTED
            This value indicates the map_name value was not valid.
          *CM_PRODUCT_SPECIFIC_ERROR
State Changes
This call does not cause a state change.  If more than one data record type
is supported this service must be invoked prior to a SEND_DATA.

Usage Notes
Programs which only have one map name, e.g., have only one data record type
can ignore this service.  The MAP_NAME for a mapped conversation has a
default value of 1.

Related Information
LU 6.2 CRM's use this service to set the MAP_NAME parameter on the
MC_SEND_DATA service to "YES (value of the Set_Map MAP_NAME parameter)".
OSI TP CRM's passes the service's MAP_NAME parameter to the U-ASE which:

     1.Encodes the data record using the proper abstract syntax. Note,
           there is no need to transmit the map_name because it is
           carried as the tag for the specific ASN.1 construct used
           to encode the data.
     2.Performs any other user defined action on the data record.
           An example of this would be a security transformation on
        the data record.
 --------------------------------------------------------------------

Extract_Map_Name (CMEXMP)

A program uses the Extract_Map_Name (CMEXMP) call to communicate to the
local system what data record is to be sent.  The receiving program
uses the Extract_Map_Name to retrieve the name of the data record
it was sent.

Depending on the underlying CRM the data record may be further
processed when it is given to the local system at SEND_DATA time,
see usage notes.

Format
CALL CMSTMP    (conversation_ID,
               map_name,
               return_code)
Parameters
Conversation_ID (input)
     Specifies the variable containing the conversation identifier
     assigned to the conversation.
map_name (output)
     Specifies the mapping function used to encode the data
     record.  This is a positive integer value.
return_code (output)
     Specifies the result of call execution.  The return_code
     variable can have one of the following values:
       *CM_OK
       *CM_PROGRAM_STATE_CHECK
         This value indicates the underlying CRM does not support
         mapped conversations.
       *CM_OPERATION_NOT_ACCEPTED
         This value indicates the map_name value is unknown to
         the CRM.
       *CM_PRODUCT_SPECIFIC_ERROR

State Changes
This call does not cause a state change.  If more than one data record
type is supported this service must be invoked after a RECEIVE.

Usage Notes
Programs which only have one map name, e.g., have only one data record
type can ignore this service.  The MAP_NAME for a mapped conversation
has a default value of 1.

Related Information
LU 6.2 CRM MC_RECEIVE_XXX services will have the MAP_NAME parameter set
to the incoming map_name.

OSI TP CRM U-ASEs will know what the map name is from the ASN.1 tag of
the incoming user data record.  The Extract_Map_Name service is used
to find out what data record was sent so that it can be properly
processed.

 ---- end service calls ----

Map Names:
Naming is a local matter, and assumed to be between the application
programmer and the CRM encoding/decoding routine programmer.  Integers
were chosen because they seemed easy to use.  If alpha-numeric names
are desired the map_name parameter can be defined as an enumerated type.

How it works in the OSI Environment:
The OSI ASN.1 encoding mechanism makes implementing and using these
calls quite simple.  ASN.1 is a self defining encoding method because
everything is encoded in a type, length, value format.

This format supports:
     1.Universal types, such as integer and Boolean, defined by
        the ASN.1 standard.
     2.Application types assigned by other standards.  In practice
           they are also assigned by users.
     3.Private types assigned by an enterprise.  In practice this
        type and the application type are used interchangeably.
     4.Context-specific types defined according to the context in
           which they are used.  The decoding of this type requires
           the decoder to understand the structure of the resulting
        decoded data stream.

Most often an abstract syntax will be a collection of application or
privately defined constructed types (data records).

Encoding is accomplished by the application issuing a SET_MAP_NAME
and then a send data.  The CRM's U-ASE calls the correct routine to
perform the encoding.Decoding is the reverse of encoding.  the CRM's
U-ASE receives an ASN.1 encoded data stream.  By examining the first
tag it can determine what type of record it is and call the correct
decoding routine.  The decoding routine will provide the locally
correct map name.

How it works in the LU 6.2 Environment:
The proposed calls will use the LU 6.2 Map-name parameter to communicate
the map name. The underlying LU 6.2 CRM mapper will invoke the correct
routine to perform the proper encoding and decoding.

Interoperability:
The basic assumption one must make is that both sides of a session
(association) have agreed to exchange a specific set of data records
in a specified network format (transfer syntax).  If these two
conditions are not met there can be not communications so the issue
of mapped conversations is mute.

The use of these calls is not predicated on both sides using them.
If the sending side does not support these calls, but the receiving
side does:
     1.An OSI based application would encode the data inside the
       application.
     2.An LU 6.2 based application would either perform any required
        encoding in the application and/or do what it does today,
           pass it to the LU 6.2 CRM for buffering.

If the receiving side does not support these calls, but the sending
side does:
     1.An OSI based application would perform the decoding in
           the application.
     2.An LU 6.2 based application would perform any required
           decoding in the application, and/or the LU 6.2 CRM would
           reassemble the data record.

Clearly, Interoperability is not affected if both sides do not
support these calls.
 ----------------------------------------------------------------------
 -Footnote 1-

"Maps are non-SNA-defined transformation tables or procedures that can be
defined by the installation at both the source and target LUs.
Maps can specify, for example, how fields of a mapped-conversation are
related to TP variables (data record) referred to in protocol-boundary
verbs."  "Mapping is performed by a PS.MC component called the mapper."
SNA Format and Protocol Reference Manual: Architecture Logic
for LU Type 6.2, SC30-3269,  page 2-3